Method and system for inter and intra agency communication, tracking and coordination

ABSTRACT

A method of tracking at least one emergency service provider is disclosed. An electronic history is compiled that includes at least one identifier of a service provider, at least one identifier of an event to which the service provider responded, and GPS data identifying the geographic location of the service provider at each time interval within the duration of the event. A user interface within which is displayed a first identifier of a first event is generated to a display device. A selection of the event identifier is received from a user. In response to the selection of the identifier, an aerial view of a geographic region within which the first event took place is generated. At least one icon is displayed in the aerial view representing the service provider at the geographic location corresponding to at least one time interval during the event.

CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY CLAIM

The present application is a continuation of U.S. patent applicationSer. No. 16/917,182 filed Jun. 30, 2020. This application also claimspriority from U.S. Provisional Application No. 62/609,942, filed Dec.22, 2017. The present application is a continuation-in-part of U.S.application Ser. No. 14/213,995, filed Mar. 14, 2014, which claimspriority from U.S. Provisional Application No. 61/792,517, filed Mar.15, 2013, and U.S. Provisional Application No. 61/905,701, filed Nov.18, 2013. All of the aforementioned applications are hereby incorporatedby reference in their entireties as if fully set forth herein.

BACKGROUND OF THE INVENTION

Coordination among different first-responder agencies, such as police,ambulance and fire, within a community and among agencies in differentcommunities is critical to the well-being of such community(ies).Consequently, a system and/or method that allows visual tracking, inreal-time or as near to real-time as is technologically possible, of thelocation, velocity and bearing of emergency vehicles would bebeneficial. Moreover, a system and/or method that allows a comprehensivevisual review of coordination efforts after an emergency event ofemergency vehicles responding to such event would be likewisebeneficial.

BRIEF DESCRIPTION OF THE DRAWING

Preferred and alternative examples of the present invention aredescribed in detail below with reference to the following drawingfigures:

FIG. 1 is a schematic view of an exemplary operating environment inwhich an embodiment of the invention can be implemented;

FIG. 2 is a functional block diagram of an exemplary operatingenvironment in which an embodiment of the invention can be implemented;

FIGS. 3-5 illustrates processes according to one or more embodiments ofthe invention; and

FIGS. 6-33 are screenshots illustrating functionality of one or moreembodiments of the invention.

DETAILED DESCRIPTION

This patent application is intended to describe one or more embodimentsof the present invention. It is to be understood that the use ofabsolute terms, such as “must,” “will,” and the like, as well asspecific quantities, is to be construed as being applicable to one ormore of such embodiments, but not necessarily to all such embodiments.As such, embodiments of the invention may omit, or include amodification of, one or more features or functionalities described inthe context of such absolute terms.

FIG. 1 illustrates an example of a computing system environment 100 inwhich an embodiment of the invention may be implemented. The computingsystem environment 100, as illustrated, is an example of a suitablecomputing environment; however, it is appreciated that otherenvironments, systems, and devices may be used to implement variousembodiments of the invention as described in more detail below.

Embodiments of the invention are operational with numerousgeneral-purpose or special purpose computing system environments orconfigurations. Examples of well-known computing systems, environments,and/or configurations that may be suitable for use with embodiments ofthe invention include, but are not limited to, personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set-top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

Embodiments of the invention may be described in the general context ofcomputer-executable instructions, such as program modules being executedby a computer. Generally, program modules include routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. Embodiments of theinvention may also be practiced in distributed-computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices. Additionally,the entity that may implement, or otherwise provide the ability toimplement, elements of embodiments of the invention may be referred toherein as an “administrator.”

With reference to FIG. 1 , an exemplary system for implementing anembodiment of the invention includes a computing device, such ascomputing device 100. The computing device 100 typically includes atleast one processing unit 102 and memory 104.

Depending on the exact configuration and type of computing device,memory 104 may be volatile (such as random-access memory (RAM)),nonvolatile (such as read-only memory (ROM), flash memory, etc.) or somecombination of the two. This most basic configuration is illustrated inFIG. 1 by dashed line 106.

Additionally, the device 100 may have additional features, aspects, andfunctionality. For example, the device 100 may include additionalstorage (removable and/or non-removable) which may take the form of, butis not limited to, magnetic or optical disks or tapes. Such additionalstorage is illustrated in FIG. 1 by removable storage 108 andnon-removable storage 110. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Memory104, removable storage 108 and non-removable storage 110 are allexamples of computer storage media. Computer storage media includes, butis not limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium which can be used tostore the desired information and which can be accessed by device 100.Any such computer storage media may be part of device 100.

The device 100 may also include a communications connection 112 thatallows the device to communicate with other devices. The communicationsconnection 112 is an example of communication media. Communication mediatypically embodies computer-readable instructions, data structures,program modules or other data in a modulated data signal such as acarrier wave or other transport mechanism and includes any informationdelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics set or changed in such a manner as toencode information in the signal. By way of example, the communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, radio-frequency (RF),infrared and other wireless media. The term computer-readable media asused herein includes both storage media and communication media.

The device 100 may also have an input device 114 such as keyboard,mouse, pen, voice-input device, touch-input device, etc. Further, anoutput device 116 such as a display, speakers, printer, etc. may also beincluded. Additional input devices 114 and output devices 116 may beincluded depending on a desired functionality of the device 100.

According to one or more embodiments, the combination of software orcomputer-executable instructions with a computer-readable medium resultsin the creation of a machine or apparatus. Similarly, the execution ofsoftware or computer-executable instructions by a processing deviceresults in the creation of a machine or apparatus, which may bedistinguishable from the processing device, itself, according to anembodiment.

Correspondingly, it is to be understood that a computer-readable mediumis transformed by storing software or computer-executable instructionsthereon. Likewise, a processing device is transformed in the course ofexecuting software or computer-executable instructions. Additionally, itis to be understood that a first set of data input to a processingdevice during, or otherwise in association with, the execution ofsoftware or computer-executable instructions by the processing device istransformed into a second set of data as a consequence of suchexecution. This second data set may subsequently be stored, displayed,or otherwise communicated. Such transformation, alluded to in each ofthe above examples, may be a consequence of, or otherwise involve, thephysical alteration of portions of a computer-readable medium. Suchtransformation, alluded to in each of the above examples, may also be aconsequence of, or otherwise involve, the physical alteration of, forexample, the states of registers and/or counters associated with aprocessing device during execution of software or computer-executableinstructions by the processing device.

As used herein, a process that is performed “automatically” may meanthat the process is performed as a result of machine-executedinstructions and does not, other than the establishment of userpreferences, require manual effort.

Referring now to FIG. 2 , an embodiment of the present invention maytake the form, and/or may be implemented using one or more elements, ofan exemplary computer network system 200. The system 200 includes anelectronic client device 210, such as a personal computer orworkstation, tablet or smart phone, that is linked via a communicationmedium, such as a network 220 (e.g., the Internet), to an electronicdevice or system, such as a server 230. The server 230 may further becoupled, or otherwise have access, to a database 240 and a computersystem 260. Although the embodiment illustrated in FIG. 2 includes oneserver 230 coupled to one client device 210 via the network 220, itshould be recognized that embodiments of the invention may beimplemented using one or more such client devices coupled to one or moresuch servers.

The client device 210 and the server 230 may include all or fewer thanall of the features associated with the device 100 illustrated in anddiscussed with reference to FIG. 1 . The client device 210 includes oris otherwise coupled to a computer screen or display 250. The clientdevice 210 may be used for various purposes such as network- andlocal-computing processes.

The client device 210 is linked via the network 220 to server 230 sothat computer programs, such as, for example, a browser, running on theclient device 210 can cooperate in two-way communication with server230. The server 230 may be coupled to database 240 to retrieveinformation therefrom and to store information thereto. Database 240 mayhave stored therein data (not shown) that can be used by the server 230and/or client device 210 to enable performance of various aspects ofembodiments of the invention. The data stored in database may include,for example, satellite and other aerial map data, including geographicinformation system (GIS)-layer data, automated vehicle locating (AVL)data and keyhole markup language (KML) data. Additionally, the server230 may be coupled to the computer system 260 in a manner allowing theserver to delegate certain processing functions to the computer system.In an embodiment, most or all of the functionality described herein maybe implemented in a desktop application 270 that may include one or moreexecutable modules. In an embodiment, the client device 210 may bypassnetwork 220 and communicate directly with computer system 260.

Still referring to FIG. 2 , and in operation according to an embodimentof the invention, a user (not shown) of the client device 210 desiringto track or review the performance of one or more emergency-responsevehicles may invoke the desktop application 270. Alternatively, the usermay invoke a browser running on the client device 210 to access webcontent, which may, but need not, be served by the server 230.Specifically, by employing an appropriate uniform resource locator (URL)in a known manner, the user may navigate to a website hosted by theserver 230.

FIG. 3 illustrates a process 300, according to an embodiment of theinvention, for tracking a set of at least one emergency serviceprovider. The process 300 is illustrated as a set of operations shown asdiscrete blocks. One or more steps of the process 300 may be implementedin any suitable hardware, software, including instructions embodiedwithin components, firmware, or combination thereof. The order in whichthe operations associated with the process 300 are described is not tobe necessarily construed as a limitation.

At a block 310, an electronic history is compiled. The electronichistory includes at least one identifier of a service provider and GPSdata identifying the geographic location of each service provider ateach time interval within a time period. For example, the client device210, server 230 and/or computer system 260 may regularly (e.g., everyfive seconds or other predetermined time interval) receive, via network220 or other conventional means, AVL data from transmitters in a set ofemergency response vehicles and correlate this data with respectiveidentifiers of these response vehicles that are stored in database 240and/or a memory device associated with client device 210. Such data willtypically take the form of a latitude/longitude position of the responsevehicle and the time at which such vehicle is in such position.Consequently, the electronic history that this correlative activityyields is configured to enable a processing device to determine thegeographic location of a given response vehicle at, for example,five-second intervals within a time period of interest.

At a block 320, the electronic history is stored in a memory device. Forexample, once the position data has been correlated with the serviceprovider identifiers to yield the electronic history, such history isstored in the database 240, for example.

At a block 330, a user interface is generated to a display device withinwhich is displayed a first identifier of a first service provider of theset of at least one service provider. For example, and referring to FIG.6 , the client device 210 may generate to the display 250 a menu 600populated with user-selectable identifiers 610 of each response vehiclefor which viewable tracking is available. For each identifier 610, themenu 600 may further identify the agency type 620 of the associatedvehicle. Alternatively, the user interface may include a data entryfield into which the user may enter, in a conventional manner, anidentifier of a response vehicle for which viewable tracking isavailable.

At a block 340, a selection of the first service-provider identifier isreceived from a user via the user interface. For example, and againreferring to FIG. 6 , using a conventional pointer device (not shown),the user may select an identifier 610 of a response vehicle that theuser wishes to track. Additionally, the user may select from the userinterface a particular time period of interest (e.g., one or more days,one or more hours during a particular day, etc.), the activity of theselected response vehicle during which the user is interested in seeing.In an embodiment, this user selection of vehicle identifier and timeperiod of interest may be transmitted to the server 230.

At a block 350, in response to the selection of the firstservice-provider identifier, an aerial view of a geographic regionwithin which the first service provider was located during the timeperiod is generated to a display device. For example, upon receiving aselection of identifier 610 and, consequently, a selection of a responsevehicle of interest, the client device may access the database 240, orother memory device, in which the electronic history is stored. From theelectronic history, the client device 210 can determine the geographicregion(s) in which the selected response vehicle was located during theselected time period of interest. Subsequently, the client device 210can, in a conventional manner, generate to display 250 a rendering ofthe determined geographic region(s) using aerial map data, for example,that may be stored in database 240 or on the client device itself.

At a block 360, at least one icon representing the first serviceprovider at the geographic location corresponding to at least one timeinterval of the set of time intervals is displayed in the aerial view.For example, in the aerial view 700 illustrated in FIG. 7 , depending onthe duration of the user-selected time period of interest, one or moreicons 710 illustrating the activity of the selected response vehicle aresuperimposed on the rendered geographic region 720 determined at block350. In the illustrated example, a comparatively lengthy time period ofinterest has been selected by the user, as evidenced by the large numberof icons 710 depicting a police unit's comprehensive patrol overvirtually the entirety of a large island part of the region 720. Ofcourse, in at least one embodiment, icons illustrating the movement ofmore than one such response vehicle may be simultaneously displayed insimilar fashion in the aerial view 700.

In an embodiment, in response to user selection of an icon 710, thevelocity and bearing of the vehicle at the time associated with theselected icon is displayed in the aerial view 700. Additionally, theelectronic history may further comprise identifiers of dispatch callsreceived by one or more of the emergency response vehicles.Consequently, an icon 730 may be displayed in the aerial view 700illustrating a geographic location of the response vehicle at a timethat the response vehicle received a dispatch call.

FIG. 4 illustrates a process 400, according to an embodiment of theinvention, for tracking a set of at least one emergency serviceprovider. The process 400 is illustrated as a set of operations shown asdiscrete blocks. One or more steps of the process 400 may be implementedin any suitable hardware, software, including instructions embodiedwithin components, firmware, or combination thereof. The order in whichthe operations associated with the process 400 are described is not tobe necessarily construed as a limitation.

At a block 410, an electronic history is compiled. The electronichistory includes at least one identifier of a service provider, at leastone identifier of an event to which the service provider responded, andGPS data identifying the geographic location of each service provider ateach time interval within the duration of the event. The event is of afinite duration. For example, the client device 210, server 230 and/orcomputer system 260 may regularly (e.g., every five seconds or otherpredetermined time interval) receive, via network 220 or otherconventional means, AVL data from transmitters in a set of emergencyresponse vehicles and correlate this data with respective identifiers ofthese response vehicles and identifiers of and information associatedwith emergency-response events to which such vehicles responded. Theidentifiers of these response vehicles and identifiers of andinformation associated with emergency-response events may be stored indatabase 240 and/or a memory device associated with client device 210.The AVL data will typically take the form of a latitude/longitudeposition of the response vehicle and the time at which such vehicle isin such position. Consequently, the electronic history that thiscorrelative activity yields is configured to enable a processing deviceto determine the geographic location of a given response vehicle at, forexample, five-second intervals within the duration of an event.Additionally, the information stored in database 240 and/or clientdevice 210 may further enable the inclusion in the electronic history ofdata identifying the geographic location of a given response vehicle attime intervals occurring prior and/or subsequent to the duration of theevent. This latter feature may be implemented by, for example, employingthe process 300 described above.

At a block 420, the electronic history is stored in a memory device. Forexample, once the position and event data has been correlated with theservice provider identifiers to yield the electronic history, suchhistory is stored in the database 240, for example.

At a block 430, a user interface is generated to a display device withinwhich is displayed a first identifier of a first event of the set of atleast one event. For example, and referring to FIG. 8 , the clientdevice 210 may generate to the display 250 a menu 800 populated withuser-selectable identifiers 810 of events to which response vehicles,for which viewable tracking is available, responded. For each identifier810, the menu 800 may further display a description 820 of the event,the address 830 of the event, identifiers 840 of the response vehiclesresponding to the event and identifiers 850 of the date/time of theevent.

At a block 440, a selection of the first event identifier is receivedfrom a user via the user interface. For example, and again referring toFIG. 8 , using a conventional pointer device (not shown), the user mayselect an identifier 810 of an event to which response vehicles, forwhich viewable tracking is available, responded.

At a block 450, in response to the selection of the first eventidentifier, an aerial view of a geographic region within which the firstevent took place is generated to a display device. For example, uponreceiving a selection of identifier 810 and, consequently, a selectionof an event of interest, the client device 210 may access the database240, or other memory device, in which the electronic history is stored.From the electronic history, the client device can determine thegeographic region in which the selected event took place. Subsequently,the client device 210 can, in a conventional manner, generate to display250 a rendering of the determined geographic region using aerial mapdata, for example, that may be stored in database or on the clientdevice itself.

At a block 460, at least one icon representing at least one respondingservice provider at the geographic location corresponding to at leastone time interval within the duration of the event is displayed in theaerial view. For example, as illustrated in FIG. 9 , two responsevehicles responded to the event selected from menu 800. Consequently,depending on the number of time intervals selected by the user forviewing, two sets of one or more icons 910, 911 illustrating therespective activity of the two response vehicles in transit to andarriving at the scene of the event are superimposed on the renderedgeographic region 920 determined at block 450.

In an embodiment, in response to user selection of an icon 910, 911, thevelocity and bearing of the vehicle at the time associated with theselected icon is displayed in the aerial view 900. Additionally, theelectronic history may further comprise identifiers of dispatch callsreceived by one or more of the emergency response vehicles, as well asidentifiers of one or more event locations to which such responsevehicles travel in response to a dispatch call. Consequently, a callicon 930 may be displayed in the aerial view 900 illustrating ageographic location of one or more of the response vehicles at a timethat such response vehicle received a dispatch call. Similarly, an eventicon 940 may be displayed in the aerial view 900 illustrating the eventlocation(s) to which such response vehicles traveled in response to adispatch call. In an embodiment, a selection of the event icon 940 bythe user may cause information about the event, such as the address ofthe event, time of event, the type of event, etc. to be displayed in theaerial view 900.

FIG. 5 illustrates a process 500, according to an embodiment of theinvention. The process 500 is illustrated as a set of operations shownas discrete blocks. One or more steps of the process 500 may beimplemented in any suitable hardware, software, including instructionsembodied within components, firmware, or combination thereof. The orderin which the operations associated with the process 500 are described isnot to be necessarily construed as a limitation.

At a block 510, identification information for at least one serviceprovider is obtained. For example, identifiers of emergency responsevehicles, identical or similar to those discussed above with referenceto process 300, for example, may be stored in, and accessible by server230 and/or client device 210 from, database 240 and/or a memory deviceassociated with the client device.

At a block 520, location information for the at least one serviceprovider is obtained. For example, the client device 210, server 230and/or computer system 260 may regularly (e.g., every five seconds orother predetermined time interval) receive, via network 220 or otherconventional means, AVL data from transmitters in a set of emergencyresponse vehicles and correlate this data with respective identifiers ofthese response vehicles that are stored in database 240 and/or clientdevice 210. Such data will typically take the form of alatitude/longitude position of the response vehicle and the time atwhich such vehicle is in such position.

At a block 530, data is obtained enabling the generation to a displaydevice of an aerial view of a geographic region in which the locationinformation indicates the at least one service provider has been intransit. For example, the client device 210 can determine, based on theidentification information and/or location information, the geographicregion(s) in which a selected response vehicle was located during agiven time period or, for example, a user-selected time period ofinterest. Subsequently, the client device 210 can, in a conventionalmanner, generate to display 250 a rendering of the determined geographicregion(s) using aerial map data, for example, that may be stored indatabase 240 or on the client device itself.

At a block 540, the map information is displayed overlaid with ananimated rendering of the movement of the at least one service providerwithin the geographic region. For example, as illustrated in FIG. 10 ,the activity of a selected response vehicle is superimposed as a “slugtrail” 1010 on the rendered geographic region 1020 determined at block530. In an embodiment, the brighter and thicker the slug trail, the morefrequently the unit drove along that particular stretch of road.

In one aspect, a system, referred to herein as Real-Time Agency ActivityDisplay and Reporting (RAADAR), is described. RAADAR is a system and/orsoftware designed to provide near real-time information for FirstResponders (Police and Fire) about the nature of the calls they areassigned to. RAADAR can provide more information than is communicatedover the radio, including notes from 911 call receivers, maps, aerialimagery, automatic vehicle location and building safety information.

In some aspects, RAADAR may be a custom web-based tool designed for realtime or near-real time display of information relating to active 911calls, for example, for or across a number of different member agencies.An important aspect of RAADAR, as distinguished from prior systems, isthat it can provide users real-time updates to 911 calls in progress.

Use of RAADAR may require a user to have a valid login into the website. RAADAR does not allow users to self-register; users need to bepre-approved by agency administrative staff before they are given accessto RAADAR. Once a user has a valid RAADAR login, they are able to seeactive 911 calls for the agencies they have been given permission toview. RAADAR offers per-agency filtering on a per-user basis so that auser can see some, all or none of member agencies. Users can also befiltered between Police and Fire so that they do not see calls from theother discipline.

Once in RAADAR, calls can be opened and more details seen. Detailsinclude the unit(s) assigned to the call, their status, a map of thecall location and where the units assigned to the call are at and ascrolling list of comments from 911 call receivers and dispatchers.Static information is also displayed that can include PrePlaninformation (building safety for fire personnel), Response Planinformation (resource assignments for fire agencies), caution notes,location name, address, person name, phone number, latitude andlongitude. RAADAR also has a Call Search feature that allows users tosearch for calls on a number of criteria.

RAADAR may include a software application, for example, created orprogrammed using Microsoft ASP .NET and Visual C#programming languages.The application may run as a custom web site that is available to anyonewith a valid login and an internet connection. In some cases, RAADAR maybe designed specifically to be run as a web site. The preferredapplication is to run RAADAR on a Microsoft Windows Server usinginternet Information Services to serve end users.

In one aspect, RAADAR consists of many Active Server Pages (ASP) andcustom computer executable code libraries (e.g., totaling 32,975 linesof C#code). Version Control may, in some cases, be maintained withMicrosoft's Team Foundation Server. RAADAR's functionality is driven bycustom code libraries. Some of the functions of these libraries includethe following.

RAADAR can independently connect to 25 different databases on 15distinct Microsoft SQL database servers. Custom libraries may retrievethe data and convert it to a common format for display to the end user.

The described system can create on-the-fly active server pages todisplay the data to the end user. The described system can connect to aWindows File server to retrieve saved audio files (911 call and radioaudio). The saved audio files can be converted to MP3 files via anothercustom library before they are downloaded to the end user.

The described system can connect to the Tyler Mobile Server to retrieveXML files associated with Mobile Field Reports. These files are parsedand appropriate data is displayed to the end user in the form of a SAPCrystal Report. Additional code in RAADAR enables the Crystal Report tobe saved as an Excel spreadsheet or PDF document. A code library mayconnect to the Snohomish County Emergency Radio System (SERS) and sendspages to specified SERS.

Custom libraries enable the end user to search for calls on a variety ofdifferent criteria (partial address, agency, call type, date range,etc.). Libraries can be used to control what features of RAADAR userssee. There are many roles defined for users; each role allows themaccess to a different feature in RAADAR. Custom libraries also connectto external agencies, and can retrieve call data and integrate itseamlessly into the user interface. Custom libraries can also retrieveunit AVL data and format it into a file suitable for displaying inGoogle Earth, or other mapping or similar visualization application.This file is downloaded to the end user and can be used for severalpurposes, such as to evaluate where a given unit was during a certaintimeframe, observing the routes taken by emergency services personnel toan incident, evaluating patrol patterns to determine if neighborhoods ina jurisdiction are being adequately covered, or for incident commandersensuring that a perimeter has been adequately set up or if moreresources are needed. Custom libraries can also be used also determinewhich live stream to connect to on a given call if a user is authorizedto listen to real time radio traffic.

Specific features of RAADAR include utilizing Ajax technology to onlyrefresh parts of web pages that have changed. This results in incrediblyfast refreshes of information displayed by RAADAR.

RAADAR can display all calls being dispatched by a 911 center regardlessof CAD system in use, such that two CAD systems nay be in use from twodifferent vendors (Tyler Technologies and TriTech Systems). Both CADsystems are highly dissimilar in look-and-feel, functionality andpurpose. Further, each CAD's database architecture is vastly differentand incompatible with each other. RAADAR is able to gather data fromboth CAD systems and display it in the same user interface to the enduser. The end user does not know that there are two different CADsystems—the only difference the end user sees is color-scheme changesfor police vs. fire incidents.

RAADAR also has the ability to generate KML files from AVL (AutomaticVehicle Location) data which can be displayed in Google Earth. This KMLdata is also animated so command staff can evaluate the routes taking byFirst Responders enroute to an incident. Other uses for the KML fileswould be to evaluate patrol patterns in a givenneighborhood/district/patrol shift. Patterns can be evaluated to see ifpatrols should be increased in a given area or if patrols are evenlydistributed across their assigned area.

In some aspects, RAADAR may be enhanced to include real-time radiotraffic. This allows agency command staff the ability to listen to radiotraffic outside of the 800 MHz coverage area. Command staff that are notinvolved in the incident can now listen to radio traffic and be informedof actions by field personnel as they happen.

In addition, a new enhancement to RAADAR allows it to link to recordingsof the call and radio traffic associated with an incident. This givesPublic Records staff and agency prosecutors instant access to recordingswithout requiring using a separate application to search for therecordings in question.

In some aspects, one or more of the features described herein may beused in conjunction with one or more aspects of the system andtechniques describe in related U.S. patent application Ser. No.14/213,995, which is included at the end of this application. Thefeatures described herein may integrate with, utilize various aspectsof, or in essence run on top of or in addition to the systems describedin U.S. patent application Ser. No. 14/213,995.

The described systems and software may provide real-time information toFirst Responders in a unified format regardless of the Computer-AidedDispatch (CAD) system used by the 911 dispatch center. RAADAR gathersCAD data directly from databases and presents it to the end user in aunified user interface. RAADAR may provide First Responders moreinformation about the nature of 911 calls and events they are respondingto. This information goes beyond what can be transmitted over the radioand includes notes from the call receiver (information gathered from theindividual calling 911), maps, aerial imagery, automatic vehiclelocation, vehicle mapping, agency resource status, and numerousreporting tools.

TriTech Systems has a similar product named Visinet. Visinet does notprovide the same level of real-time information, does not updateautomatically, and does not integrate data from disparate CAD systems.However, TriTech Visinet Web Browser does not meet the same purpose asRAADAR. Visinet is more of a reporting tool for after-incident usewhereas RAADAR is targeted at getting information to users in real-time.

Tyler Technologies also has a similar product named CAD WebView. It is abasic web interface that provides minimal information to end users. CADWebView appears to be more of a porting of Tyler's Aegis Mobile softwareapplication to a web format. CAD WebView also is not able to aggregateCAD data from disparate sources and display it in a common userinterface. However, Tyler's CAD WebView has relied on a third-partydisplay tool that is unstable and buggy. During testing and evaluationof CAD WebView in 2011, users found it to be unstable, limited, andultimately unusable. Issues cited included disliking the user interfaceand hard-coded limits on searching in addition to instability problems.

Features according to one or more embodiments may include the following:

Police and Fire Reports and Redaction

Feature set capability allows users to pull up active call information.Additional capability allows user to pull a pre-formatted report of thecall or provide a redacted report for public records requests, whichstrips the call of all protected or personal data not eligible forpublic records requests.

Agency Paging Capabilities

Feature set capability allows RAADAR to integrate paging logs (FIG. 11), manual and group paging (FIG. 12 ) capabilities within RAADAR toreport pages sent from RAADAR and to send mass notification to emergencyservices personnel from RAADAR. Paging groups are predefined based onagency and organizational need and access security is provided throughRAADAR application layer security.

Active Call to Active 911 Phone and Radio Recording Capability

Feature set capability allows RAADAR to pull active call, in-progresscall information and link call to voice and radio information related tothe call (FIG. 13 ). The enhancement enables users, administrativereview, prosecutor review, and public records specialists the capabilityto use RAADAR to collect call information in one place. RAADAR linksCAD/911 information to another system which logs all voice and radiotraffic specific to the incident event.

Active Call and Live Streaming Radio

Feature set capability allows RAADAR to stream audio traffic from liveradio events through the integration of trunk tracking scanner hardwaredirectly connected to a server which RAADAR can access (FIG. 14 ). A“live” 911 call or incident can be tracked and radio traffic to thefield units can be listened to via internet and monitored “live” as theevent is occurring, while also monitoring field and dispatch notes viaRAADAR interface and unit history reporting.

Link to Fire Response Plans

Allows RAADAR to display a link to the Fire Agency Response Plans for agiven address. A “live” 911 call or incident can be tracked by units inthe field and a response plan can be viewed by incident commandersshowing what resources a given problem nature requires (FIGS. 15A and15B).

Link to PrePlan Documents

RAADAR includes a link to the Fire Agency Response PrePlan document(s)for a given address. A “live” 911 call or incident can be tracked byunits in the field and a building safety plan can be viewed by incidentcommanders (FIGS. 16A and 16B).

Current Traffic Report

RAADAR links to the WSDOT web site to display the latest traffic map forarea freeways. This allows first responders to choose the best route toa given location e.g. medic unit transporting to Level 1 Trauma Center(FIGS. 17A and 17B).

Zone 1 Resource Availability

From a single page in RAADAR, fire agency command staff can get a quickoverview of resource allocation across a zone. This may includedisplaying units that are in quarters, have been moved up to anotherstation to provide coverage, are out of service or are assigned to anincident (FIG. 18 ).

Mobile Report Viewer

RAADAR allows Police Records Staff to see field reports being created bypatrol staff. This allows Records Staff and Crime Analysts to see fieldreports as they are being worked on from any computer (FIGS. 19A and19B).

Chat Audit

Allows supervisory staff to review chat messages sent betweendispatchers and/or mobile field units (FIG. 20 ).

Call Alerts

RAADAR checks for active alerts associated with a given Call forService. If RAADAR finds an active Order of Protection, Officer Safetyor Stolen Vehicle alert, an appropriate button will appear in the CallDetails page as illustrated in FIG. 21 .

Clicking on the button will display the text of the alert as illustratedin FIG. 22 .

Electronic Personnel Accountability Safety System (ePASS)

The implementation of ePASS in RAADAR is meant to enhance informationavailable to Fire Agency Incident Commanders and is a replacement for amanual system consisting of Velcro radio ID numbers and apparatusdesignators.

Personnel Profile

A new Personnel Profile page has been created in RAADAR to trackinformation related to the position the fire personnel holds. Theseinclude assigned RadioIDs, pager(s), rank and certifications asillustrated in FIG. 23 .

Passport Radio Assignments

The designated ePASS officer is able to assign radio IDs and personnelto the various positions on a given apparatus.

From the Radio Assignments page, the officer first selects the firestation he's working at. The stations are filtered to only display theofficer's home agency stations (e.g., a Shoreline FD user will not seeBellevue FD stations) as illustrated in FIG. 24 .

Next, he selects the apparatus to assign personnel to as illustrated inFIG. 25 .

By clicking on one of the Radio ID entries, a new window opens upallowing the officer to modify the assignment as illustrated in FIG. 26.

The Personnel drop-down is filtered to agency personnel. Radio IDs canbe changed from this page and will be saved in the database asillustrated in FIG. 27 .

Incident Command

A new Incident Command page is available to designated agency IncidentCommanders. Typically, these are Battalion Chiefs.

From the Call Details page, the Commander clicks the Incident Commandbutton to access the Incident Command page as illustrated in FIG. 28 .

The Incident Command page includes two timers—Call Timer whichcalculates the elapsed time since the call was created in CAD and 1stOnScene Timer which calculates the elapsed time since the first unitarrived on scene.

The address of the incident is prominently displayed at the top of thepage. Below that are the Resource Passports. These are displayed foreach unit assigned to the call as illustrated in FIG. 29 .

Resource Passports

The Resource Passports are dynamically added/removed from the page basedon resources assigned to the incident. The passports are color-coded andsorted by apparatus type: First are Engines, followed by Ladders/LightForce, Battalion Chiefs, Medics, MSO, Aid and finally other supportresources. The bottom of the passport is color-coded based on the unit'sstatus (Dispatched/En Route/At Scene/Transporting). A further sort isdone in each classification of unit based on the CAD-calculated ETA.

Clicking on the Apparatus Name will expand the passport to reveal theRadio IDs and personnel assigned to the apparatus as illustrated in FIG.30 .

Note that the passport will automatically contract back to the compactdisplay after 30 seconds.

Call Narratives

These are the narratives as entered by call receivers and/or dispatchersat NORCOM. This list updates in near real-time and the newest entriesare on top.

Emergency Radio Activations

RAADAR is constantly watching for a CAD narrative entry indicating wehave received an Emergency Radio Activation from one of the radiosassociated with personnel assigned to the incident. If an emergencyactivation is detected, an alert flashes on the Incident Command page asillustrated in FIG. 31 .

By clicking the Acknowledge button, the alert is acknowledged and loggedalong with the timestamp of the acknowledgement. The alert no longerdisplays after it has been acknowledged.

Apparatus Profile

Individual apparatus profiles can also be edited from within RAADAR. Thefirst step is to have the apparatus added to the ePASS role. When addedto the ePASS role, the apparatus user now has the ePASS sub menu underthe Profile menu as illustrated in FIG. 32 .

Pager(s):

Clicking in this grid allows you to edit the pager informationassociated with the apparatus.

Mobile Radio(s):

Clicking this grid allows the mobile radio ID to be edited. It is alsopossible to add multiple mobiles to an apparatus, where appropriate(e.g. Light Force).

Other Radios:

This grid allows you to edit the position name and associated Radio IDon a given apparatus. You can also click the Add New Radio button tocreate another radio position on the apparatus.

TriTech/CentralSquare InformCAD Integration

The information saved on the ePASS Personnel Profile page as well as theradio assignments are also saved in InformCAD. This allows the FireDispatchers to have the same information available to them in CAD thatthe incident commanders have in RAADAR.

Profile Settings

A new page has been added to RAADAR to enable the end-user to managetheir profiles. Users are able to update their E-mail address and selecta list of agencies to display in RAADAR based on the agencies they havebeen assigned permission to view as illustrated in FIG. 33 .

While the preferred embodiment of the invention has been illustrated anddescribed, as noted above, many changes can be made without departingfrom the spirit and scope of the invention. For example, at least oneembodiment described above herein may be implemented in connection withFire and EMS units, in addition to the Police units discussed in theillustrated examples. Additionally, at least one embodiment describedabove herein may be implemented with respect to non-emergency serviceproviders, such as mail and package delivery, grocery delivery, andlarge scale transportation operations such as shipping and airlines. Anembodiment may include GIS layers, for example, that enable theplacement in the aerial view 700, 900 of police and fire stationlocations, as well as fire response areas and police beats. In anembodiment, icons representing the station locations, response areas andor beats may be selected by user, in response to which iconsrepresenting movement of all units associated with suchlocations/areas/beats may be automatically shown in the aerial view 700,900. Additionally, clicking on any of the icons representing a responseunit may open up a window, for example, indicating the unit's call sign,their location, and the timestamp of that particular AVL plot.Additionally, an embodiment may include animation controls associatedwith the aerial view 700, 900 enabling a user to control the speed atwhich the icons representing response vehicles are sequentially placedin the aerial view to illustrate the movement of the corresponding unit.These controls also enable the user to control the length of the icon“vector” (i.e., the number of icons shown at any given time toillustrate movement of the corresponding vehicle) during the animationwithin the aerial view 700, 900. Moreover, the electronic historiesdescribed above may be processed in such a manner as to allow the userto view movement of a vehicle in “near real-time” in the aerial view700, 900. Accordingly, the scope of the invention is not limited by thedisclosure of the preferred embodiment. Instead, the invention should bedetermined entirely by reference to the claims that follow.

The embodiments of the invention in which an exclusive property orpriviiege is claimed are defined as follows:
 1. At least onenon-transitory computer-readable medium including instructions that,when executed by at least one processing device, enable the at least oneprocessing device to perform a method, the method comprising the stepsof: accessing over a network first and second computer-aided dispatchdatabases, the first database including a first data set in a firstformat, the second database including a second data set in a secondformat different from the first format, each of the first and seconddata sets characterizing at least one response to at least one incidentby at least one emergency response vehicle; retrieving over the networkfrom the first and second databases the first and second data sets;converting the first and second data sets to a third data set in a thirdformat different from the first and second formats; and presenting on adisplay device the third data set in a graphical user interface (GUI),wherein the third data set enables the GUI to present via a speakerradio traffic involving the at least one emergency response vehicle. 2.The medium of claim 1, wherein the third data set comprises real-timeupdates characterizing the at least one response.
 3. The medium of claim1, wherein the GUI comprises a web page.
 4. The medium of claim 1,wherein the third data set enables the GUI to display the location ofthe at least one emergency response vehicle.
 5. The medium of claim 1,wherein the third data set enables the GUI to display messages sentbetween a dispatcher and the at least one emergency response vehicle. 6.The medium of claim 1, wherein the method further comprises displaying atraffic map for a predetermined geographic region.
 7. Acomputer-implementable method comprising the steps of: accessing over anetwork first and second computer-aided dispatch databases, the firstdatabase including a first data set in a first format, the seconddatabase including a second data set in a second format different fromthe first format, each of the first and second data sets characterizingat least one response to at least one incident by at least one emergencyresponse vehicle; retrieving over the network from the first and seconddatabases the first and second data sets; converting the first andsecond data sets to a third data set in a third format different fromthe first and second formats; and presenting on a display device thethird data set in a graphical user interface (GUI), wherein the thirddata set enables the GUI to present via a speaker radio trafficinvolving the at least one emergency response vehicle.
 8. The method ofclaim 7, wherein the third data set comprises real-time updatescharacterizing the at least one response.
 9. The method of claim 7,wherein the GUI comprises a web page.
 10. The method of claim 7, whereinthe third data set enables the GUI to display the location of the atleast one emergency response vehicle.
 11. The method of claim 7, whereinthe third data set enables the GUI to display messages sent between adispatcher and the at least one emergency response vehicle.
 12. Themethod of claim 7, wherein the method further comprises displaying atraffic map for a predetermined geographic region.